Methods for discovering and paying debts owed by a group

ABSTRACT

Ranking payment requests includes a peer-to-peer payment system that employs a server configured for receiving a payment request from a requester computing device; receiving location data of the requester network device; receiving a request for a ranking of payment requests; searching social network information of the payor for occurrences of the requester of the payment request; receiving location data of the payor network device, the location data comprising a location of the payor computing device and a location history of the payor computing device; searching a transaction history of the payor; ranking the payment requests based at least in part on one or more of the location of the requester, a strength of social network connections to the payor for each of the payment requesters, and number of previous transactions between the payor and the requester; and providing the ranking of the payment requests to the payor.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/148,704 filed Jan. 6, 2014 and entitled “Methods for Discovering andPaying Debts Owed by a Group,” which is a continuation of U.S. Pat. No.8,700,526 filed Dec. 5, 2012 and entitled “Methods for Discovering andPaying Debts Owed by a Group.” The entire contents of theabove-identified priority applications are hereby fully incorporatedherein by reference.

TECHNICAL FIELD

The present disclosure relates generally to peer-to-peer transactions,and more particularly to using social networking content and locationdata of a user to rank payment requests.

BACKGROUND

Users of smartphones and other similar devices are conducting anincreasing number of electronic transactions with the devices. Whilefinancial transactions with merchants have become more user-friendly andcommonplace, users are additionally employing their devices to conducttransactions with other mobile device users. These types of conventionalpeer-to-peer transactions often require an overwhelming amount of datainput to identify the other party in the transaction and to conduct thetransaction.

Users of this technology are desirous of a simpler and faster method oflocating the details of a transaction request. An example of acircumstance in which users may conduct this type of peer-to-peertransaction is when multiple parties are paying a bill while dining at arestaurant. If one person pays the restaurant for the bill of a group ofdiners and the other members of the party would like to pay that personfor each share of the bill, entering information for the transactionwould be burdensome.

Conventional systems do not present a list of likely transactions thatare recommended for a payor. Additionally, such systems do not present arank or order of the most likely transactions.

SUMMARY

Techniques herein provide a computer-implemented method to providepayment requests to potential payors. The method comprises receiving,using one or more computer devices, a payment request from a requestercomputing device; associating an identifier to the request; receivinglocation data of the requester network device, the location dataindicating a location of the requester computing device at a time ofinitiating the request; receiving a request for a ranking of paymentrequests for a potential payor from a payor computing device; searchingsocial network information of the payor for occurrences of the requesterof the payment request; receiving location data of the payor networkdevice, the location data comprising a location of the payor computingdevice and a location history of the payor computing device; searching atransaction history of the payor for occurrences of the requester of thepayment request; ranking the payment requests based at least in part onone or more of the location of the requester, a strength of socialnetwork connections to the payor for each of the payment requesters, andnumber of previous transactions between the payor and the requester; andproviding the ranking of the payment requests to the payor for displayon the payor computing device.

Another aspect of the present invention provides a computer programproduct that is installed on a server located in a payment system toprovide payment requests to potential payors. The computer programproduct includes a non-transitory computer-readable storage devicehaving computer-readable program instructions stored therein. Thecomputer-readable program instructions include computer programinstructions for receiving, using one or more computer devices, apayment request from a requester computing device; associating anidentifier to the request; receiving location data of the requesternetwork device, the location data indicating a location of the requestercomputing device at a time of initiating the request; receiving arequest for a ranking of payment requests for a potential payor from apayor computing device; searching social network information of thepayor for occurrences of the requester of the payment request; receivinglocation data of the payor network device, the location data comprisinga location of the payor computing device and a location history of thepayor computing device; searching a transaction history of the payor foroccurrences of the requester of the payment request; ranking the paymentrequests based at least in part on one or more of the location of therequester, a strength of social network connections to the payor foreach of the payment requesters, and number of previous transactionsbetween the payor and the requester; and providing the ranking of thepayment requests to the payor for display on the payor computing device.

These and other aspects, objects, features and advantages of the exampleembodiments will become apparent to those having ordinary skill in theart upon consideration of the following detailed description ofillustrated example embodiments, which include the best mode of carryingout the invention as presently presented.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for providing paymentrequests to potential payors, in accordance with certain exampleembodiments.

FIG. 2 is a block flow diagram depicting a method to provide paymentrequests to potential payors, in accordance with certain exampleembodiments.

FIG. 3 is a block flow diagram depicting a method for identifying apotential payor, in accordance with certain example embodiments.

FIG. 4 is a block flow diagram depicting a method for selecting a rankedpayment request, in accordance with certain example embodiments.

FIG. 5 is a block diagram depicting a computing machine and a module, inaccordance with certain example embodiments.

DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS Overview

The example embodiments provide a Peer-to-Peer (“P2P”) payment systemthat can employ a user's social graph and location data for identifyinglikely potential payors for a group transaction or other debt. In orderto receive the benefits of the techniques described herein, in certainembodiments, the user will have to install an application, use aparticular service, or otherwise engage in the techniques herein. Thepotential payors can locate the payment request and satisfy the request.The social graph of a user refers to all of a user's contacts, friends,family, and other members of a user's online network. The social graphcan be any combination of social networks of the user, contact databasesof the user, lists of email correspondents of the user, lists offrequent transaction counter-parties of the user, and any other suitablesocial graph data.

The social graph not only determines the members of a user's network,but also determines how the members are related and how closely themembers are related.

In an example embodiment, the payment requester can pay a bill at amerchant for a group of users. For example, the requester and the groupcan dine at a restaurant and receive a bill for payment. Instead ofsplitting the bill into numerous smaller bills, one person can pay forthe group. In another example, a group of users desire to pay for abirthday gift. Instead of collecting money or trying to gather everyonetogether to make the purchase, one user can buy the gift for the group.Any other suitable group debt can be incurred and require repayment ofthe debt to a group member who pays the debt.

The group member who pays the debt can submit a request for repayment onthe P2P payment application operating on the user device of therequester. The P2P payment application can transmit the request to theP2P payment system. The request can be transmitted via any availabletechnology such as an Internet connection over the network, email, text,or any other suitable communication technology. Alternatively, therequester can make the request on a website of the P2P payment system orvia any other suitable method.

In an alternate example embodiment, the request can be managed byanother party other than the P2P payment system. Any server system canbe employed to host the request and monitor the repayment of the debts.For example, a social network system can manage the request. In anotherexample, a bank, credit card issuer, or other suitable financialinstitution can manage the request. In another example, a dedicatedgroup payment server system can manage the request.

The request can be a summary of the debt owed to the requester or anyother suitable format to identify the debt. For example, the requestercan attach a copy or other representation of the bill or receipt. Inanother example, the requester can manually enter the request details.In another example, the P2P payment application can attach the billpayment transaction details from a P2P transaction or other transaction.In another example, the requester can assign specific amounts for eachpayor to submit, such as by assigning receipt line items to individualpayors. In another example, the requester can manually input a differentamount for each individual payor. Any other suitable format for therequest can be submitted by the requester.

The requester, the P2P payment application, the P2P payment system, orother suitable party assigns an identifier to the request. Theidentifier may be any code, text, picture, or other suitable identifierthat will allow a payor to identify and select the correct request forpayment. The request can be a descriptive identifier input by therequester, such as the date and location of the incurred debt. Forexample, the identifier could be “Outback Friday at Lunch” or “10 PM atTarget.” The identifier could be the name or a nickname of therequester, a name of the group, a name of the company the payors have incommon, or other name identifier. For example, the identifier could be“Grandma Smith gift” or “Jones Company outing.”

The identifier can be a randomly generated code. The code can begenerated by the P2P payment application, the P2P payment system, orother suitable party. A random code can allow the request to beanonymous and help protect the identity of the transaction, therequester, and the payors. The random code can be any alphanumeric codesuch as “abc123” or one or more random words. Any other suitable randomcode can be employed. The requester can inform the payors of the randomcode verbally, via email, via text, or via any other suitable manner.

The request can be a visual representation. For example, a picture ofthe event, an avatar of the requester, a random picture or drawing, orany other visual identifier can be used.

The P2P payment system can identify potential payors for the request.The P2P payment system can identify the potential payors from thelocation of the requester and the location of the potential payors, fromthe social graph of the recipient and the potential payors, by manualinput of the recipient, from any other suitable methods or combinationof methods.

The P2P payment application can employ the Global Positioning System(“GPS”) location technology or other location identifying technology ofthe user device of the requester to transmit the location of the device,and thus the location of the requester. The location can be transmittedto a server located in a P2P payment system. The P2P payment applicationcan gather the location data directly from the user device or the P2Ppayment application can request the location from another location-basedapplication operating on the user device. In another example, the P2Ppayment application can determine the location of the user device from adevice supplying a Wi-Fi connection. In another example, the recipientcan employ a social network application or other suitable application tomanually enter the location of the requester or “check in.” Any othersuitable location determination hardware or software can be employed.

The P2P payment system searches for other mobile devices operating in apredetermined proximity of the requester. The P2P payment system can usethe same location technologies to locate the potential payor devicesthat the P2P payment system used to locate the recipient or any otherlocation technology.

The proximity threshold can be configured by the requester or the P2Ppayment system. The proximity threshold can further be variable basedupon factors predetermined by the requester or the P2P payment system.For example, the P2P payment system may vary the proximity based on thedensity of the potential payors identified or the quantity of socialnetwork data available from the requester's accounts. The P2P paymentsystem can first gather the location data and identity of other usersthat have accounts on the P2P payment system. Additionally oralternatively, the P2P payment system can be configured to communicatewith other location-based programs or applications that can supplylocation data and user identity to the P2P payment system server.

Additionally or alternatively, the location recorded by a potentialpayor at the time of the request can be determined at a later time. Forexample, if the recipient entered the request at a time after leavingthe location of the transaction, the P2P payment system can determinethe transaction time and location and look for potential payors thatwere at the location at the time of the transaction. The potentialpayors may have an application that has logged the locations of thepayor and the P2P payment system can extract the location at the time ofthe transaction. Additionally or alternatively, the potential payor mayhave “checked in” to the location and thus the P2P payment system canextract the location form the “check in” application. Any other suitablelocation determining method may be utilized to determine which potentialpayors may have been at the transaction location.

The P2P payment system can identify potential payors in the social graphof the recipient. From the social graph data, the P2P payment systemsearches the identities of the requester's contacts, friends, businessassociates, family members or any other identities that can beextracted.

The P2P payment system can gather the identities from any social networkdata available from the recipient's online activities. Examples oflocations available from which the P2P payment system may gather datamay include, but not be limited to, social network websites accounts,contact list entries, email contacts, or other programs and applicationsrunning on recipient user devices.

The P2P payment system can rank the identities based on a set ofcriteria configured to determine the most likely potential payors to theuser's transaction. One of the criteria used by the P2P payment systemto rank the results can be based on the status of the contact on thesocial network status, such as a “friend” on a social network or afriend of a friend. If a friend is on the ranking list, then the friendsof that friend may be included on the list and given a certain priority.Other criteria may include, but would not be limited to, frequency ofemails or texts with a contact, physical distance from user based on thelocation data, previous transactions with the recipient, or recentactivation of the P2P payment system application on the device.

Additionally or alternatively, the P2P payment system compares the listof proximate user identities with a compilation of social network datafrom the user. Any combination of the location data, social graph data,or other identification or ranking criteria can be employed to identifypotential payors.

The P2P payment system, the recipient, or another suitable party canestablish a threshold for an identified contact to be put on thepotential payor list. The threshold may be based on the closeness of thesocial graph relationship, the proximity of the user device of thecontact, the number of applications on the social graph in which thecontact appears, or any suitable factor or combination of factors. TheP2P payment system can compare the list of identified contacts to thethreshold and determine which contacts to include on the potentialpayors list.

Additionally or alternatively, the recipient can manually input thepotential payors to be included in the list. For example, the recipientcan input the name or other identify of every potential payor. Inanother example, the recipient can request that every social networkcontact is identified as a potential payor. In another example, therecipient can request that every contact associated with the employer ofthe recipient is identified as a potential payor. In another example,the recipient can request that only contacts with which the recipienthas had a previous P2P transaction are identified as potential payors.Any other suitable input from the recipient can assist in determiningthe potential payors.

In an alternate example embodiment, after generating a ranked list ofpotential payors, the P2P payment system can transmit the list to theP2P payment application on the user device of the recipient. Therecipient can edit the names and accounts on the list of potentialpayors on a user interface.

The P2P payment system can issue the payment request to the potentialpayors. For example, the identification of the request can be listed onthe account of the potential payor. In another example, the request canbe emailed to the potential payor, texted to the potential payor,transmitted to a P2P payment application operating on the user device ofthe potential payor via an Internet connection, or in any suitablemanner transmitted to the potential payor. In another example, a list ofrequests can be displayed on a website of the P2P payment system.

In an alternate example embodiment, the P2P payment system can providethe list of payment requests to all payors who access the P2P paymentsystem. That is, the identifiers are available to every payor forselection. The payor can search the list of all payment requests andselect the appropriate request.

The payor can open the P2P payment application to view the requests forpayment. Additionally or alternatively, the payor can access the accountof the payor on the website of the P2P payment system or via any othersuitable application or website. The payor can access a page or optionthat displays a ranked list of payment requests associated with thepayor. For example, the payor can actuate a real or virtual button, opena link to a website, speak a voice command or in any suitable mannerrequest the list of requests. The payor can view the list of requests inany format available to the user interface being utilized.

The P2P payment system identifies payment requests that are previouslyassociated with the payor. For example, the P2P payment system canidentify payment requests that identified the name of the payor or theaccount of the payor. In another example, the P2P payment system canidentify payment requests that were associated with the payor account atthe time of the request. The payor may have been associated with apayment request in any other suitable manner.

The P2P payment system accesses the location of the payor device at thetime that the payor accesses the payment application or views a list ofrequests. The P2P payment system additionally or alternatively, accessesthe location history of the payor. The location can be obtained from anyhardware, software, or combination of hardware and software that canprovide a location of the device. For example, the global positioningsystem technology of the device can be used. In another example, thelocation can be determined from one or more Wi-Fi systems thatcommunicate with the payor device. In another example, the location canbe determined from a check in on a social network system or otherlocation logging application or website. Any suitable locationidentifying technology can be employed.

The P2P payment system accesses and searches the social graph of thepayor. The social graph of a user refers to all of a user's contacts,friends, family, and other members of a user's online network. Thesocial graph can be any combination of social networks of the payor,contact databases of the payor, lists of email correspondents of thepayor, lists of frequent transaction counter-parties of the payor, andany other suitable social graph data. The search of the social graph notonly determines the members of a network of the payor, but alsodetermines how the members are related and how closely the members arerelated.

The P2P payment system accesses and searches the transaction history ofthe payor. The transaction history can include some or all of the P2Ptransactions of the payor or any other suitable transactions accessibleby the P2P payment system. The history may include the identities oraccounts of transaction counter-parties or any suitable identifyingcharacteristic.

The P2P payment system displays a ranked list of payment requests forthe payor. The P2P payment system can use the location history of thepayor, the social graph information of the payor, and the transactionhistory of the payor to rank the payment requests. The payor canindicate a desire to have the P2P payment system use the data for thepurposes of ranking the payment requests. The user can indicate thisdesire by installing the P2P payment application, providingauthorization for the ranking, or otherwise engaging in the techniquesherein.[1]

The P2P payment system can rank the requests by determining therelatedness of the generator of the requester to the payor, thetransaction history of the requester and the payor, the relatedness ofthe location history of the payor and the location at which the paymentrequest was generated, or any other suitable ranking criteria.

In an example embodiment, the P2P payment system can compare thelocation history of the payor to the location of the payment request.For example, the P2P payment system can identify the location of therequester device at the time of the request and determine if the payorwas near the identified location at or near the time the request wasentered. Based on a determination that the payor was near the identifiedlocation at or near the time the request was entered, the P2P paymentsystem can promote the request on the list of payment requests to bepresented to the payor.

In another example, the P2P payment system can identify a merchantassociated with a receipt included with the payment request. The P2Ppayment system can determine if the payor device was at the merchant atthe time of the request or at any other time. Based on a determinationthat the payor was near the identified location, the P2P payment systemcan promote the request on the list of payment requests to be presentedto the payor.

In another example, the P2P payment system can determine if therequester associated with a request is related to the payor on thesocial graph of the payor. From the social graph data, the P2P paymentsystem searches the identities of associates of the requester such ascontacts, friends, business associates, family members or any otheridentities that can be extracted.

The P2P payment system may gather the account identities from any socialnetwork data available from the recipient's online activities. Examplesof locations available from which the P2P payment system may gather datamay include, but not be limited to, social network websites accounts,contact list entries, email contacts, or other programs and applicationsrunning on recipient user devices.

The P2P payment system can use the relatedness of the requestors to thepayor to rank the requests. One of the criteria used by the P2P paymentsystem to determine the relatedness can be based on the status of thecontact on the social network status, such as a “friend” on a socialnetwork or a friend of a friend. Other criteria may include, but wouldnot be limited to, frequency of emails or texts with a contact, physicaldistance from user based on the location data, previous transactionswith the recipient, or recent activation of the P2P payment systemapplication on the device. Based on the relatedness of a requestor, arequest may be promoted or demoted on the ranking of requests.

In another example embodiment, the number of previous transactionsbetween a payor and a requester of a payment request can be used to rankthe request. For example, if a payor and a requester have many previousP2P transactions, then a request generated by the requester may bepromoted on the ranking of requests.

In another example embodiment, the payor can search for a request with aspecific identifier. For example, the identifier may be any code, text,picture, or other suitable identifier that will allow the payor toidentify and select the correct request for payment. The request can bea descriptive identifier input by the requester, such as the date andlocation of the incurred debt. For example, the identifier could be“Outback Friday at Lunch” or “10 PM at Target.” The identifier could bethe name or a nickname of the requester, a name of the group, a name ofthe company the payors have in common, or other name identifier. Forexample, the identifier could be “Grandma Smith gift” or “Jones Companyouting.”

In an alternative exemplary embodiment, the identifier can be a randomlygenerated code. The code can be generated by the P2P paymentapplication, the P2P payment system, or other suitable party. A randomcode can allow the request to be anonymous and help protect the identityof the transaction, the requester, and the payors. The random code canbe any alphanumeric code such as “abc123” or one or more random words.Any other suitable random code can be employed. The requester can informthe payors of the random code (or any other identifier) verbally, viaemail, via text, or via any other suitable manner.

If the payor searches for a payment request, and the request identifiermatches the search keywords, then the payment request can be promoted onthe request ranking list.

In another alternative exemplary embodiment, the identifier can be avisual representation. For example, a picture of the event, an avatar ofthe requester, a randomly generated picture or drawing, or any othervisual identifier can be used.

The display can be presented to the payor on the P2P paymentapplication, on the website of the P2P payment system, or on any othersuitable user interface. The display can present the top rankedrequests, such as the top 5 or top 10 ranked requests. The display canpresent all of the requests that are associated with the payor. Thedisplay can present a ranked list of all requests in the system. Anyother suitable display of the ranked list of requests can be employedand presented to the user.

The payor can select the request that the payor would like to pay. Withthe user interface on a P2P payment application, the payor can pay theamount that is requested or the payor can enter an alternate amount topay. If the request is on the P2P payment system then the P2P paymentsystem can fill in the data to conduct the transaction with theinformation of the recipient, the payor, and the transaction details.Alternatively, the payor can manually enter the information or selectinformation from a list on the user interface.

The payor can alternatively pay the recipient in another manner, such ascash or a check, and update the request on the P2P payment system. Thatis, the payor can utilize the user interface on the P2P paymentapplication or a website of the P2P payment system and manually enter anamount paid to the recipient. The P2P payment system can update therequest with the entered information. Alternatively, the P2P paymentsystem may require a confirmation of the payment from the recipientbefore the request is updated.

Example System Architectures

Turning now to the drawings, in which like numerals represent like (butnot necessarily identical) elements throughout the figures, exampleembodiments of the present invention are described in detail.

FIG. 1 is a block diagram depicting a system for using social networkcontent and location data to identify likely counter-parties for apeer-to-peer transaction with a mobile device, in accordance withcertain exemplary embodiments. As depicted in FIG. 1, the system 100includes network devices 110, 120, 150, and 160 that are configured tocommunicate with one another via one or more networks 105.

Each network 105 includes a wired or wireless telecommunication means bywhich network devices (including devices 110, 120, 150, 160) canexchange data. For example, each network 105 can include a local areanetwork (“LAN”), a wide area network (“WAN”), an intranet, an Internet,a mobile telephone network, or any combination thereof. Throughout thediscussion of example embodiments, it should be understood that theterms “data” and “information” are used interchangeably herein to referto text, images, audio, video, or any other form of information that canexist in a computer-based environment.

Each network device 110, 120, 150, 160 includes a device having acommunication module capable of transmitting and receiving data over thenetwork 105. For example, each network device 110, 120, 150, 160 caninclude a server, desktop computer, laptop computer, tablet computer, atelevision with one or more processors embedded therein and/or coupledthereto smart phone, handheld computer, personal digital assistant(“PDA”), or any other wired or wireless, processor-driven device. In theexample embodiment depicted in FIG. 1, the network devices 110, 120,150, 160 are operated by end-users or consumers, likely transactioncounter-party users, publishers of social network system, and apeer-to-peer payment system operator, respectively.

The user 101 can use a communication application 112, such as a webbrowser application or a stand-alone application, to view, download,upload, or otherwise access documents or web pages via a distributednetwork 105. The network 105 includes a wired or wirelesstelecommunication system or device by which network devices (includingdevices 110, 120, 150, 160) can exchange data. For example, the network105 can include a local area network (“LAN”), a wide area network(“WAN”), an intranet, an Internet, storage area network (SAN), personalarea network (PAN), a metropolitan area network (MAN), a wireless localarea network (WLAN), a virtual private network (VPN), a cellular orother mobile communication network, Bluetooth, NFC, or any combinationthereof or any other appropriate architecture or system that facilitatesthe communication of signals, data, and/or messages. Throughout thediscussion of exemplary embodiments, it should be understood that theterms “data” and “information” are used interchangeably herein to referto text, images, audio, video, or any other form of information that canexist in a computer based environment.

The communication application 112 can interact with web servers (orother computing devices) connected to the network 105, payor device 120,web server 151 of the social network system 150, and the web server 161of the P2P payment system 160.

The user network device 110 may include a digital wallet applicationmodule 111. The digital wallet application module 111 may encompass anyapplication, hardware, software, or process the user device 110 mayemploy to assist the user 101 in completing a purchase. The digitalwallet application module 111 can interact with the communicationapplication 112 or can be embodied as a companion application of thecommunication application 112. As a companion application, the digitalwallet application module 111 executes within the communicationapplication 112. That is, the digital wallet application module 111 maybe an application program embedded in the communication application 112.The payor device 120 operated by the payor 102 can use a communicationapplication 122 similar to the communication application 112.

The user device 110 can include a P2P payment application 115. The P2Ppayment application 115 can interact with the communication application112 or be embodied as a companion application of the communicationapplication 112 and execute within the communication application 112.The P2P payment application 115 may additionally or alternatively beembodied as a companion application of the digital wallet applicationmodule 111 and execute within the digital wallet application module 111.The P2P payment application 115 may employ a software interface forconfiguration that may open in the digital wallet application module 111or may open in the communication application 112. Alternatively, the P2Ppayment application 115 may execute on the user device 110 independentof the digital wallet application module 111 and the communicationapplication 112.

The P2P payment application 115 is operable to allow a user 101 toconfigure payment accounts on the user device 110 and the P2P paymentsystem 160. The P2P payment application 115 can be used to send devicelocation data to the P2P payment system 160 and receive a likelytransaction list from the P2P payment system 160. The P2P payment system160 that develops the list and prosecutes the transaction can include aset of computer-readable program instructions, for example, usingJavaScript, that enable the P2P payment system 160 to interact with theP2P payment application 115. The payor device 120 operated by a payor102 can use a P2P payment application 125 similar to the P2P paymentapplication 115 or a compatible transaction application that will allowtransactions with the user device 110.

The user device 110 also includes a data storage unit 113 accessible bythe digital wallet application module 111, the P2P payment application115, and the communication application 112. The example data storageunit 113 can include one or more tangible computer-readable storagedevices. The data storage unit 113 can be stored on the user device 110or can be logically coupled to the user device 110. For example, thedata storage unit 113 can include on-board flash memory and/or one ormore removable memory cards or removable flash memory.

The user device 110 may include a location based application 114 thatthe P2P payment application 115 or the P2P payment system 160 mayutilize to access location data for the user device 110. Examples ofapplications that may utilize the location data, and thus may make itavailable to the P2P payment system 160, may include, but would not belimited to, business finder applications, location based socialnetworks, location based gaming, or friend locater applications. Thepayor device 120 can utilize a location application 124 that is similarto the location based application 114.

The user device 110 may include one or more contact applications 116. Acontact application 116 may be any program or application on the userdevice 110 that maintains a list of contacts of the user that the P2Ppayment system 160 may access. Examples of contact applications 116might include, but not be limited to, email applications, textapplications, instant messaging, calendar invite lists, or contactdatabases. The contacts from a contact application 116 may beprioritized by factors such as frequency of communication with user 101,the number of contact applications on which a particular contactappears, or any other prioritizing factors which may be extracted fromthe applications.

The payor device 120 may represent the devices with which the user 101may conduct a peer-to-peer transaction or other transaction. Like theuser device 110, the payor device 120 may be a mobile device, (forexample, notebook computer, tablet computer, netbook computer, personaldigital assistant (PDA), video game device, GPS locator device, cellulartelephone, a television with one or more processors embedded thereinand/or coupled thereto smart phone, smartphone, or other mobile device),or other appropriate technology that includes or is coupled to acommunication application 112.

The P2P payment system 160 utilizes a P2P payment system server 161. TheP2P payment system server 161 may represent the computer implementedsystem that the P2P payment system 160 employs to configure useraccounts, create and maintain user profiles, collect the location data,communicate with the social network system 150, develop likelytransaction lists, submit the list to the user 101 or the payor 101, andconduct the transaction. The P2P payment system website 163 mayrepresent any web-based interface that allows users to interact with theP2P payment system 160 to configure the user accounts and change accountsettings. The P2P payment system server 161 can communicate with one ormore social network systems 150, one or more payor devices 120, and auser device 110 via any available technologies. These technologies mayinclude, but would not be limited to, an Internet connection via thenetwork 105, email, text, instant messaging, or other suitablecommunication technologies. The P2P payment system 160 may include adata storage unit 162 accessible by the server 161 of the PPS 160. Thedata storage unit 162 can include one or more tangible computer-readablestorage devices.

The social network system 150 utilizes a social network system server151. The social network server 151 may represent thecomputer-implemented system that the social network system 150 employsto host the social network website 153 and all of the profiles andcommunities that use the social network website 153. The social networkwebsite 153 may represent any web-based community that allows users tointeract over the Internet with others who typically share a commoninterest.

The social network system 150 may provide the P2P payment system 160with a list of members of the user's online community. The socialnetwork system 150 may prioritize the relationship of each member of thecommunity with the user 101. This may be determined by factors that mayapply to the structure of each particular social network system 150. Forexample, a social network system may categorize members of the communityas “friends” or “friends of friends.” Another social network system maycategorize members as first, second, or third degree contacts.

The social network system server 151 can communicate with a P2P paymentsystem 160 and user devices 110 and payor devices 120 via any availabletechnologies. These technologies may include, but would not be limitedto, an Internet connection via the network 105, email, text, instantmessaging, or other suitable communication technologies. The socialnetwork system 150 may include a data storage unit 152 accessible by theserver 151 of the social network system 150. The data storage unit 152can include one or more tangible computer-readable storage devices.

Example Processes

The components of the example operating environment 100 are describedhereinafter with reference to the example methods illustrated in FIGS.2.

FIG. 2 is a block flow diagram depicting a method 200 to provide paymentrequests to potential payors, in accordance with certain exampleembodiments.

With reference to FIGS. 1 and 2, in block 205, a user 101 initiates arequest for payment. The user (or “requester”) 101 can pay a bill at amerchant for a group of users. For example, the requester 101 and thegroup can dine at a restaurant and receive a bill for payment. Insteadof splitting the bill into numerous smaller bills, one person can payfor the group. In another example, a group of users desire to pay for abirthday gift. Instead of collecting money or trying to gather everyonetogether to make the purchase, one user can buy the gift for the group.Any other suitable group debt can be incurred and require repayment ofthe debt to a group member who pays the debt.

The group member who pays the debt, the requester 101, can submit arequest for repayment on the P2P payment application 115 operating onthe user device 110 of the requester. The P2P payment application 115can transmit the request to the P2P payment system 160. The request canbe transmitted via any available technology such as an Internetconnection over the network, email, text, or any other suitablecommunication technology. Alternatively, the requester 101 can make therequest on a website 161 of the P2P payment system 160 or via any othersuitable method.

In an alternate example embodiment, the request can be managed byanother party other than the P2P payment system 160. Any server systemcan be employed to host the request and monitor the repayment of thedebts. For example, a social network system 150 can manage the request.In another example, a bank, credit card issuer, or other suitablefinancial institution can manage the request. In another example, adedicated group payment server system can manage the request.

The request can be a summary of the debt owed to the requester 101 orany other suitable format to identify the debt. For example, therequester 101 can attach a copy or other representation of the bill orreceipt. In another example, the requester 101 can manually enter therequest details. In another example, the P2P payment application 115 canattach the bill payment transaction details from a P2P transaction orother transaction. In another example, the requester 101 can assignspecific amounts for each payor 102 to submit, such as by assigningreceipt line items to individual payors 102. In another example, therequester 101 can manually input a different amount for each individualpayor 102. Any other suitable format for the request can be submitted bythe requester 101. In an alternative exemplary embodiment, the requester101 may collect funds from multiple people prior to actually paying abill or otherwise paying the funds to another party. For example, therequester 101 may collect funds from multiple people for a charity anddonate all collected funds to the charity, or may collect funds frommultiple people prior to purchasing a gift from the group of people. Inthis case, the request initiated by the requester 101 may be a generalrequest for the multiple people to contribute.

The payment application 115 is configured to receive the requester's 101input of the payment information and any other suitable details. Forexample, the payment application 115 can present a user interface on therequester device 110 with fields for the requester 101 to input theinformation. In certain exemplary embodiments, the payment application115 can access payment information from a transaction completed with therequester device 110, such as via the digital wallet application module111, and can insert the accessed payment information into thecorresponding fields of the user interface.

In block 210, the requester 101, the P2P payment application 115, theP2P payment system 160, or other suitable party assigns an identifier tothe request. The identifier may be any code, text, picture, or othersuitable identifier that will allow a payor 102 to identify and selectthe correct request for payment. The request can be a descriptiveidentifier input by the requester 101, such as the date and location ofthe incurred debt. For example, the identifier could be “SteakhouseFriday at Lunch” or “10 PM at department store.” The identifier could bethe name or a nickname of the requester 101, a name of the group, a nameof the company the payors 102 have in common, or other name identifier.For example, the identifier could be “Grandma Smith gift” or “JonesCompany outing.”

In an alternative exemplary embodiment, the identifier can be a randomlygenerated code. The code can be generated by the P2P payment application115, the P2P payment system 160, or other suitable party. A random codecan allow the request to be anonymous and help protect the identity ofthe transaction, the requester 101, and the payors 102. The random codecan be any alphanumeric code such as “abc123” or one or more randomwords. Any other suitable random code can be employed. The requester 101can inform the payors 102 of the random code (or any other identifier)verbally, via email, via text, or via any other suitable manner.

In another alternative exemplary embodiment, the identifier can be avisual representation. For example, a picture of the event, an avatar ofthe requester 101, a randomly generated picture or drawing, or any othervisual identifier can be used.

In block 215, the P2P payment system 160 can identify potential payors102 for the request. The P2P payment system 160 can identify thepotential payors 102 from the location of the requester 101 and thelocation of the potential payors 102, from the social graph of therecipient and the potential payors 102, by manual input of therecipient, from any other suitable methods or combination of methods.The details of a method to identify potential payors 102 for the requestare discussed in greater detail in the method 215 in FIG. 3.

FIG. 3 is a block flow diagram depicting a method 215 for identifying apotential payor 102, in accordance with certain example embodiments.

In block 305, the P2P payment application 115 can employ the GlobalPositioning System (“GPS”) location technology or other locationidentifying technology of the user device 110 of the requester 101 totransmit the location of the device 110, and thus the location of therequester 101. The location can be transmitted to a server 161 locatedin a P2P payment system 160. The P2P payment application 115 can gatherthe location data directly from the user device 110 or the P2P paymentapplication 115 can request the location from another location-basedapplication operating on the user device 110. In another example, theP2P payment application 115 can determine the location of the userdevice 110 from a device supplying a Wi-Fi connection. In anotherexample, the recipient 101 can employ an application from a socialnetwork system 150 or other suitable application to manually enter alocation or “check in.” Any other suitable location determinationhardware or software can be employed.

In block 310, the P2P payment system 160 searches for other mobiledevices operating in a predetermined proximity of the requester 101,such as the payor device 120. The P2P payment system 160 can use thesame location technologies to locate the potential payor devices 120that the P2P payment system 160 used to locate the recipient or anyother location technology.

The proximity threshold can be configured by the requester 101 or theP2P payment system. The proximity threshold can further be variablebased upon factors predetermined by the requester 101 or the P2P paymentsystem 160. For example, the P2P payment system 160 can vary theproximity based on the density of the potential payors 102 identified orthe quantity of social network data available from the requester 101accounts. The P2P payment system 160 can first gather the location dataand identity of other users that have accounts on the P2P paymentsystem. Additionally or alternatively, the P2P payment system 160 can beconfigured to communicate with other location-based programs orapplications that can supply location data and user identity to the P2Ppayment system server 161.

Additionally or alternatively, the location recorded by a potentialpayor 102 at the time of the request can be determined at a later time.For example, if the recipient 101 entered the request at a time afterleaving the location of the transaction, the P2P payment system 160 candetermine the transaction time and location and look for potentialpayors 102 that were at the location at the time of the transaction. Thepotential payors 102 can have an application that has logged thelocations of the payor 102 and the P2P payment system 160 can extractthe location at the time of the transaction. Additionally oralternatively, the potential payor 102 may have “checked in” to thelocation and thus the P2P payment system 160 can extract the locationform the “check in” application. Any other suitable location determiningmethod can be utilized to determine which potential payors 102 may havebeen at the transaction location.

In block 315, the P2P payment system 160 can identify potential payors102 in the social graph of the recipient 101. From the social graphdata, the P2P payment system 160 searches the identities of associatesof the requester 101 such as contacts, friends, business associates,family members or any other identities that can be extracted.

The P2P payment system 160 may gather the identities from any socialnetwork data available from the recipient's online activities. Examplesof locations available from which the P2P payment system 160 may gatherdata may include, but not be limited to, social network websitesaccounts, contact list entries, email contacts, or other programs andapplications running on recipient user devices 110.

In block 320, the P2P payment system 160 ranks the identities based on aset of criteria configured to determine the most likely potential payors102 to the user's transaction. One of the criteria used by the P2Ppayment system 160 to rank the results can be based on the status of thecontact on the social network status, such as a “friend” on a socialnetwork or a friend of a friend. If a friend is on the ranking list,then the friends of that friend may be included on the list and given acertain priority. Other criteria may include, but would not be limitedto, frequency of emails or texts with a contact, physical distance fromuser based on the location data, previous transactions with therecipient, or recent activation of the P2P payment system 160application on the device.

In block 325, the P2P payment system 160 compares the list of proximateuser identities with a compilation of social network data from the user.Any combination of the location data, social graph data, or otheridentification or ranking criteria can be employed to identify potentialpayors 102.

The P2P payment system 160, the recipient 101, or another suitable partycan establish a threshold for an identified contact to be put on thelist of potential payors 102. The threshold may be based on thecloseness of the social graph relationship, the proximity of the userdevice of the contact, the number of applications on the social graph inwhich the contact appears, or any suitable factor or combination offactors. The P2P payment system 160 can compare the list of identifiedcontacts to the threshold and determine which contacts to include on thelist of potential payors 102.

Additionally or alternatively, in block 330, the recipient 101 canmanually input the potential payors 102 to be included in the list. Forexample, the recipient 101 can input the name or other identify of everypotential payor 102. In another example, the recipient 101 can requestthat every social network contact is identified as a potential payor102. In another example, the recipient 101 can request that everycontact associated with the employer of the recipient 101 is identifiedas a potential payor 102. In another example, the recipient 101 canrequest that only contacts with which the recipient 101 has had aprevious P2P transaction are identified as potential payors 102. Therecipient 101 can input instructions to exclude any potential payors102. For example, the recipient 101 can input the name or other identityof one or more potential payors 102 that the recipient 101 does not wantincluded on any list of potential payors 102. Any other suitable inputfrom the recipient 101 can assist in determining the potential payors102.

In an alternate example embodiment, after generating a ranked list ofpotential payors 102, the P2P payment system 160 can transmit the listto the P2P payment application 115 on the user device 110 of therecipient 101. The recipient 101 can further edit the names and accountson the list of potential payors 102 on a user interface.

From block 330, the method 215 returns to block 220 in FIG. 2.

Returning to FIG. 2, in block 220, the P2P payment system 160 issues thepayment request to the potential payors 102. For example, theidentification of the request can be listed on the account of thepotential payor 102. In another example, the request can be emailed tothe potential payor 102, texted to the potential payor 102, transmittedto a P2P payment application 115 operating on the user device 120 of thepotential payor 102 via an Internet connection, or in any suitablemanner transmitted to the potential payor 102. In another example, alist of requests can be displayed on a website of the P2P payment system160.

In alternate example embodiments, the P2P payment system 160 can providethe list of payment request to all payors 102 who access the P2P paymentsystem 160. That is, the identifiers are available to every payor 102for selection. The payor 102 can search the list of all payment requestsand select the appropriate request.

In block 225, the payor can review a ranked list of payment requests andselect a request for payment. The details of block 225 are discussed ingreater detail in method 225 in FIG. 4.

Turning now to method 225 in FIG. 4, in block 405, the P2P paymentsystem 160 maintains a database of payment requests. The database canhave all payment requests that are in the system in on database.Additionally or alternatively, the database can have requests that areassociated with a requester 101 in a database or in a particularcategory in the database. Additionally or alternatively, the databasecan have the requests associated with a payor 102 in a database or in aparticular category in the database. The database can be categorized inany suitable manner. The database can be stored on the web server 161 ofthe P2P payment system 160, on a remote server, or on any other suitableweb server or storage location.

In block 410, the payor 102 can open the P2P payment application 115 toview the requests for payment. Additionally or alternatively, the payor102 can access the account of the payor 102 on the website 163 of theP2P payment system 160, or via any other suitable application orwebsite. The payor 102 can access a page or option that displays aranked list of payment requests associated with the payor 102. Forexample, the payor 102 can actuate a real or virtual button, open a linkto a website, speak a voice command or in any suitable manner requestthe list of requests. The payor 102 can view the list of requests in anyformat available to the user interface being utilized.

In block 415, the P2P payment system 160 identifies payment requeststhat are previously associated with the payor 102. For example, the P2Ppayment system 160 can identify payment requests that identified thename of the payor 102 or the account of the payor 102. In anotherexample, the P2P payment system 160 can identify payment requests thatwere associated with the payor account at the time of the request, suchas described in FIG. 3. The payor 102 may have been associated with apayment request in any other suitable manner.

In block 420, the P2P payment system 160 accesses the location of thepayor device 120 at the time that the payor accesses the P2P paymentapplication 115 or views a list of requests. The P2P payment system 160additionally or alternatively, accesses the location history of thepayor 102. The location can be obtained from any hardware, software, orcombination of hardware and software that can provide a location of thedevice 120. For example, the global positioning system technology of thedevice 120 can be used. In another example, the location can bedetermined from one or more Wi-Fi systems that communicate with thepayor device 120. In another example, the location can be determinedfrom a check in on a social network system 150 or other location loggingapplication or website. Any suitable location identifying technology canbe employed.

In block 425, the P2P payment system 160 accesses and searches thesocial graph of the payor 102. The social graph of a user refers to allof a user's contacts, friends, family, and other members of a user'sonline network. The social graph can be any combination of socialnetworks of the payor 102, contact databases of the payor 102, lists ofemail correspondents of the payor 102, lists of frequent transactioncounter-parties of the payor 102, and any other suitable social graphdata. The search of the social graph not only determines the members ofa network of the payor 102, but also determines how the members arerelated and how closely the members are related.

In block 430, the P2P payment system 160 accesses and searches thetransaction history of the payor 102. The transaction history caninclude some or all of the P2P transactions of the payor 102 or anyother suitable transactions accessible by the P2P payment system 160.The history may include the identities or accounts of transactioncounter-parties or any suitable identifying characteristic.

In block 435, the P2P payment system 160 displays a ranked list ofpayment requests for the payor 102. The P2P payment system 160 can usethe location history of the payor 102, the social graph information ofthe payor 102, and the transaction history of the payor 102 to rank thepayment requests. The P2P payment system 160 can rank the requests bydetermining the relatedness of the generator of the requester 101 to thepayor 102, the transaction history of the requester 101 and the payor102, the relatedness of the location history of the payor 102 and thelocation at which the payment request was generated, or any othersuitable ranking criteria.

In an example embodiment, the P2P payment system 160 can compare thelocation history of the payor 102 to the location of the paymentrequest. For example, the P2P payment system 160 can identify thelocation of the requester device 110 at the time of the request anddetermine if the payor 102 was near the identified location at or nearthe time the request was entered. Based on a determination that thepayor 102 was near the identified location at or near the time therequest was entered, the P2P payment system 160 can promote the requeston the list of payment requests to be presented to the payor 102.

In another example, the P2P payment system 160 can identify a merchantassociated with a receipt included with the payment request. The P2Ppayment system 160 can determine if the payor device 120 was at themerchant at the time of the request or at any other time. Based on adetermination that the payor 102 was near the identified location, theP2P payment system 160 can promote the request on the list of paymentrequests to be presented to the payor 102.

In another example, the P2P payment system 160 can determine if therequester 101 associated with a request is related to the payor 102 onthe social graph of the payor 102. From the social graph data, the P2Ppayment system 160 searches the identities of associates of therequester 101 such as contacts, friends, business associates, familymembers or any other identities that can be extracted.

The P2P payment system 160 may gather the account identities from anysocial network data available from the recipient's online activities.Examples of locations available from which the P2P payment system 160may gather data may include, but not be limited to, social networkwebsites accounts, contact list entries, email contacts, or otherprograms and applications running on recipient user devices 110.

The P2P payment system 160 can use the relatedness of the requestors 101to the payor 102 to rank the requests. One of the criteria used by theP2P payment system 160 to determine the relatedness can be based on thestatus of the contact on the social network status, such as a “friend”on a social network or a friend of a friend. Other criteria may include,but would not be limited to, frequency of emails or texts with acontact, physical distance from user based on the location data,previous transactions with the recipient, or recent activation of theP2P payment system 160 application on the device. Based on therelatedness of a requestor 102, a request may be promoted or demoted onthe ranking of requests.

In another example embodiment, the number of previous transactionsbetween a payor 102 and a requester 101 of a payment request can be usedto rank the request. For example, if a payor 102 and a requester 101have many previous P2P transactions, then a request generated by therequester 101 may be promoted on the ranking of requests.

In another example embodiment, the payor 102 can search for a requestwith a specific identifier. For example, the identifier may be any code,text, picture, or other suitable identifier that will allow the payor102 to identify and select the correct request for payment. The requestcan be a descriptive identifier input by the requester 101, such as thedate and location of the incurred debt. For example, the identifiercould be “Outback Friday at Lunch” or “10 PM at Target.” The identifiercould be the name or a nickname of the requester 101, a name of thegroup, a name of the company the payors 102 have in common, or othername identifier. For example, the identifier could be “Grandma Smithgift” or “Jones Company outing.”

In an alternative exemplary embodiment, the identifier can be a randomlygenerated code. The code can be generated by the P2P payment application115, the P2P payment system 160, or other suitable party. A random codecan allow the request to be anonymous and help protect the identity ofthe transaction, the requester 101, and the payors 102. The random codecan be any alphanumeric code such as “abc123” or one or more randomwords. Any other suitable random code can be employed. The requester 101can inform the payors 102 of the random code (or any other identifier)verbally, via email, via text, or via any other suitable manner.

If the payor 102 searches for a payment request, and the requestidentifier matches the search keywords, then the payment request can bepromoted on the request ranking list.

In another alternative exemplary embodiment, the identifier can be avisual representation. For example, a picture of the event, an avatar ofthe requester 101, a randomly generated picture or drawing, or any othervisual identifier can be used.

The display can be presented to the payor 102 on the P2P paymentapplication 115, on the website 161 of the P2P payment system 160, or onany other suitable user interface. The display can present the topranked requests, such as the top 5 or top 10 ranked requests. Thedisplay can present all of the requests that are associated with thepayor 102. The display can present a ranked list of all requests in thesystem. Any other suitable display of the ranked list of requests can beemployed and presented to the user.

In block 440, the payor 102 can select the request that the payor 102would like to pay. The payor 102 can select the request to pay byindicating the selection on the user interface. The P2P paymentapplication 115 or the P2P payment system 160 can direct the payor 102to a payment page on the user interface with the transaction datapopulated. The payor 102 can modify any entries in the payment page,such as by lowering the payment amount, changing the recipient, adding anote or message, or any other suitable modification.

From block 440, the method 225 returns to block 230 in FIG. 2.

Returning now to FIG. 2, in block 230, with the user interface on a P2Ppayment application 115, the payor 102 can pay the amount that isrequested or the payor 102 can enter an alternate amount to pay. If therequest is on the P2P payment system 160 then the P2P payment system 160can fill in the data to conduct the transaction with the information ofthe recipient 101, the payor 102, and the transaction details.Alternatively, the payor 102 can manually enter the information orselect information from a list on the user interface.

The payor 102 can alternatively pay the recipient 101 in another manner,such as cash or a check, and update the request on the P2P paymentsystem 160. That is, the payor 102 can utilize the user interface on theP2P payment application 115 or a website 163 of the P2P payment system160 and manually enter an amount paid to the recipient 101. The P2Ppayment system 160 can update the request with the entered information.Alternatively, the P2P payment system 160 may require a confirmation ofthe payment from the recipient 101 before the request is updated.

From block 230, the method 200 ends.

Other Example Embodiments

FIG. 5 depicts a computing machine 2000 and a module 2050 in accordancewith certain example embodiments. The computing machine 2000 maycorrespond to any of the various computers, servers, mobile devices,embedded systems, or computing systems presented herein. The module 2050may comprise one or more hardware or software elements configured tofacilitate the computing machine 2000 in performing the various methodsand processing functions presented herein. The computing machine 2000may include various internal or attached components such as a processor2010, system bus 2020, system memory 2030, storage media 2040,input/output interface 2060, and a network interface 2070 forcommunicating with a network 2080.

The computing machine 2000 may be implemented as a conventional computersystem, an embedded controller, a laptop, a server, a mobile device, asmartphone, a set-top box, a kiosk, a vehicular information system, onemore processors associated with a television, a customized machine, anyother hardware platform, or any combination or multiplicity thereof. Thecomputing machine 2000 may be a distributed system configured tofunction using multiple computing machines interconnected via a datanetwork or bus system.

The processor 2010 may be configured to execute code or instructions toperform the operations and functionality described herein, managerequest flow and address mappings, and to perform calculations andgenerate commands. The processor 2010 may be configured to monitor andcontrol the operation of the components in the computing machine 2000.The processor 2010 may be a general purpose processor, a processor core,a multiprocessor, a reconfigurable processor, a microcontroller, adigital signal processor (“DSP”), an application specific integratedcircuit (“ASIC”), a graphics processing unit (“GPU”), a fieldprogrammable gate array (“FPGA”), a programmable logic device (“PLD”), acontroller, a state machine, gated logic, discrete hardware components,any other processing unit, or any combination or multiplicity thereof.The processor 2010 may be a single processing unit, multiple processingunits, a single processing core, multiple processing cores, specialpurpose processing cores, co-processors, or any combination thereof.According to certain embodiments, the processor 2010 along with othercomponents of the computing machine 2000 may be a virtualized computingmachine executing within one or more other computing machines.

The system memory 2030 may include non-volatile memories such asread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), flash memory, or anyother device capable of storing program instructions or data with orwithout applied power. The system memory 2030 may also include volatilememories such as random access memory (“RAM”), static random accessmemory (“SRAM”), dynamic random access memory (“DRAM”), synchronousdynamic random access memory (“SDRAM”). Other types of RAM also may beused to implement the system memory 2030. The system memory 2030 may beimplemented using a single memory module or multiple memory modules.While the system memory 2030 is depicted as being part of the computingmachine 2000, one skilled in the art will recognize that the systemmemory 2030 may be separate from the computing machine 2000 withoutdeparting from the scope of the subject technology. It should also beappreciated that the system memory 2030 may include, or operate inconjunction with, a non-volatile storage device such as the storagemedia 2040.

The storage media 2040 may include a hard disk, a floppy disk, a compactdisc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), aBlu-ray disc, a magnetic tape, a flash memory, other non-volatile memorydevice, a solid state drive (“SSD”), any magnetic storage device, anyoptical storage device, any electrical storage device, any semiconductorstorage device, any physical-based storage device, any other datastorage device, or any combination or multiplicity thereof. The storagemedia 2040 may store one or more operating systems, application programsand program modules such as module 2050, data, or any other information.The storage media 2040 may be part of, or connected to, the computingmachine 2000. The storage media 2040 may also be part of one or moreother computing machines that are in communication with the computingmachine 2000 such as servers, database servers, cloud storage, networkattached storage, and so forth.

The module 2050 may comprise one or more hardware or software elementsconfigured to facilitate the computing machine 2000 with performing thevarious methods and processing functions presented herein. The module2050 may include one or more sequences of instructions stored assoftware or firmware in association with the system memory 2030, thestorage media 2040, or both. The storage media 2040 may thereforerepresent examples of machine or computer readable media on whichinstructions or code may be stored for execution by the processor 2010.Machine or computer readable media may generally refer to any medium ormedia used to provide instructions to the processor 2010. Such machineor computer readable media associated with the module 2050 may comprisea computer software product. It should be appreciated that a computersoftware product comprising the module 2050 may also be associated withone or more processes or methods for delivering the module 2050 to thecomputing machine 2000 via the network 2080, any signal-bearing medium,or any other communication or delivery technology. The module 2050 mayalso comprise hardware circuits or information for configuring hardwarecircuits such as microcode or configuration information for an FPGA orother PLD.

The input/output (“I/O”) interface 2060 may be configured to couple toone or more external devices, to receive data from the one or moreexternal devices, and to send data to the one or more external devices.Such external devices along with the various internal devices may alsobe known as peripheral devices. The I/O interface 2060 may include bothelectrical and physical connections for operably coupling the variousperipheral devices to the computing machine 2000 or the processor 2010.The I/O interface 2060 may be configured to communicate data, addresses,and control signals between the peripheral devices, the computingmachine 2000, or the processor 2010. The I/O interface 2060 may beconfigured to implement any standard interface, such as small computersystem interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel,peripheral component interconnect (“PCI”), PCI express (PCIe), serialbus, parallel bus, advanced technology attached (“ATA”), serial ATA(“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, variousvideo buses, and the like. The I/O interface 2060 may be configured toimplement only one interface or bus technology. Alternatively, the I/Ointerface 2060 may be configured to implement multiple interfaces or bustechnologies. The I/O interface 2060 may be configured as part of, allof, or to operate in conjunction with, the system bus 2020. The I/Ointerface 2060 may include one or more buffers for bufferingtransmissions between one or more external devices, internal devices,the computing machine 2000, or the processor 2010.

The I/O interface 2060 may couple the computing machine 2000 to variousinput devices including mice, touch-screens, scanners, biometricreaders, electronic digitizers, sensors, receivers, touchpads,trackballs, cameras, microphones, keyboards, any other pointing devices,or any combinations thereof. The I/O interface 2060 may couple thecomputing machine 2000 to various output devices including videodisplays, speakers, printers, projectors, tactile feedback devices,automation control, robotic components, actuators, motors, fans,solenoids, valves, pumps, transmitters, signal emitters, lights, and soforth.

The computing machine 2000 may operate in a networked environment usinglogical connections through the network interface 2070 to one or moreother systems or computing machines across the network 2080. The network2080 may include wide area networks (WAN), local area networks (LAN),intranets, the Internet, wireless access networks, wired networks,mobile networks, telephone networks, optical networks, or combinationsthereof. The network 2080 may be packet switched, circuit switched, ofany topology, and may use any communication protocol. Communicationlinks within the network 2080 may involve various digital or an analogcommunication media such as fiber optic cables, free-space optics,waveguides, electrical conductors, wireless links, antennas,radio-frequency communications, and so forth.

The processor 2010 may be connected to the other elements of thecomputing machine 2000 or the various peripherals discussed hereinthrough the system bus 2020. It should be appreciated that the systembus 2020 may be within the processor 2010, outside the processor 2010,or both. According to some embodiments, any of the processor 2010, theother elements of the computing machine 2000, or the various peripheralsdiscussed herein may be integrated into a single device such as a systemon chip (“SOC”), system on package (“SOP”), or ASIC device.

In situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with an opportunity to control whether programs orfeatures collect user information (e.g., information about a user'ssocial network, social actions or activities, profession, a user'spreferences, or a user's current location), or to control whether and/orhow to receive content from the content server that may be more relevantto the user. In addition, certain data may be treated in one or moreways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity may be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location may be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser may have control over how information is collected about the userand used by a content server.

Embodiments may comprise a computer program that embodies the functionsdescribed and illustrated herein, wherein the computer program isimplemented in a computer system that comprises instructions stored in amachine-readable medium and a processor that executes the instructions.However, it should be apparent that there could be many different waysof implementing embodiments in computer programming, and the embodimentsshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosedembodiments based on the appended flow charts and associated descriptionin the application text. Therefore, disclosure of a particular set ofprogram code instructions is not considered necessary for an adequateunderstanding of how to make and use embodiments. Further, those skilledin the art will appreciate that one or more aspects of embodimentsdescribed herein may be performed by hardware, software, or acombination thereof, as may be embodied in one or more computingsystems. Moreover, any reference to an act being performed by a computershould not be construed as being performed by a single computer as morethan one computer may perform the act.

The example embodiments described herein can be used with computerhardware and software that perform the methods and processing functionsdescribed previously. The systems, methods, and procedures describedherein can be embodied in a programmable computer, computer-executablesoftware, or digital circuitry. The software can be stored oncomputer-readable media. For example, computer-readable media caninclude a floppy disk, RAM, ROM, hard disk, removable media, flashmemory, memory stick, optical media, magneto-optical media, CD-ROM, etc.Digital circuitry can include integrated circuits, gate arrays, buildingblock logic, field programmable gate arrays (FPGA), etc.

The example systems, methods, and acts described in the embodimentspresented previously are illustrative, and, in alternative embodiments,certain acts can be performed in a different order, in parallel with oneanother, omitted entirely, and/or combined between different exampleembodiments, and/or certain additional acts can be performed, withoutdeparting from the scope and spirit of various embodiments. Accordingly,such alternative embodiments are included in the inventions describedherein.

Although specific embodiments have been described above in detail, thedescription is merely for purposes of illustration. It should beappreciated, therefore, that many aspects described above are notintended as required or essential elements unless explicitly statedotherwise. Modifications of, and equivalent components or actscorresponding to, the disclosed aspects of the example embodiments, inaddition to those described above, can be made by a person of ordinaryskill in the art, having the benefit of the present disclosure, withoutdeparting from the spirit and scope of embodiments defined in thefollowing claims, the scope of which is to be accorded the broadestinterpretation so as to encompass such modifications and equivalentstructures.

1-20. (canceled)
 21. A computer-implemented method to generate paymentrequests, comprising: receiving, using one or more computing devices, aplurality of payment requests from payment requesters, each paymentrequest being received from a requester computing device associated witha particular one of the payment requesters, and each payment requestcomprising identification information for the particular one of thepayment requesters, and an amount for which the particular one of thepayment requesters would like to be paid; associating, using the one ormore computing devices, a payment request identifier with each of theplurality of payment requests; receiving, using the one or morecomputing devices, a message requesting a listing of payment requests,the message being received from a payor computing device associated witha payor; searching, using the one or more computing devices, socialnetwork information of the payor for occurrences of the paymentrequesters to assess a strength of social network connections betweenthe payor and each of the plurality of payment requesters; comparing,using the one or more computing devices, location data of the payorcomputing device with location data of each of the requester computingdevices to determine whether the location of the payor computing deviceprovided in the location data for the payor computing device matches thelocation data for any of the requester computing devices; generating,using the one or more computing devices, a list of the payment requestsbased at least in part on the strength of social network connectionsbetween the payor and each of the plurality of payment requesters; andproviding, using the one or more computing devices, the list of thepayment requests to the payor computing device for display to the payorcomputing device.
 22. The computer-implemented method of claim 21,further comprising searching, using the one or more computing devices, atransaction history of the payor to identify a number of previoustransactions between the payor and each of the plurality of paymentrequestors, and wherein generating the list of the payment request isfurther based on a number of previous transactions between the payor andeach of the plurality of payment requestors.
 23. Thecomputer-implemented method of claim 21, further comprising: searching,using the one or more computing devices, for the identifier associatedwith the payment request; and promoting, using the one or more computingdevices, a payment request to the top of the listing of the paymentrequests based on the identifier of the payment request matching thesearch criteria.
 24. The computer-implemented method of claim 21,wherein the location data of the payor computing device furthercomprises a location history of the payor computing device.
 25. Thecomputer-implemented method of claim 21, wherein the payment requestidentifier is randomly generated by the one or more computing devices.26. The computer-implemented method of claim 21, further comprising:receiving, using the one or more computing devices, an input from thepayor computing device that the payor conducted a transaction to satisfyone of the payment requests; and updating, using the one or morecomputing devices, the satisfied one of the payment requests based onthe input.
 27. The computer-implemented method of claim 26, furthercomprising conducting, using the one or more computing devices, thetransaction with the payor computing device.
 28. Thecomputer-implemented method of claim 21, wherein the social networkinformation comprises a social graph of the payor.
 29. Thecomputer-implemented method of claim 21, wherein the social graphcomprises information from at least one of a social network site and acontacts application.
 30. The computer-implemented method of claim 26,wherein selection of a payment request from the list via the payorcomputing device initiates a financial transaction between the payorcomputing device and the requester computing device associated with theselected payment request.
 31. A computer program product, comprising: anon-transitory computer-readable storage device havingcomputer-executable program instructions embodied thereon that whenexecuted by a computer identifies payment requests, thecomputer-executable program instructions comprising: computer-executableprogram instructions to receive a plurality of payment requests, eachpayment request being received from a requester computing deviceassociated with a particular one of the payment requesters, and eachpayment request comprising identification information for the particularone of the payment requesters, and an amount for which the particularone of the payment requesters would like to be paid; computer-executableprogram instructions to associate a payment request identifier with eachof the plurality of payment requests; computer-executable programinstructions to receive a message requesting a listing of paymentrequests, the message being received from a payor computing deviceassociated with a payor; computer-executable program instructions tosearch social network information of the payor for occurrences of thepayment requesters to assess a strength of social network connectionbetween the payor and each of the plurality of payment requesters;computer-executable program instructions to generate a listing of thepayment requests based at least in part on the strength of socialnetwork connection between the payor and each of the plurality ofpayment requesters; and computer-executable program instructions toprovide the listing of the payment requests to the payor computingdevice for display to the payor.
 32. The method of claim 31, furthercomprising computer-executable program instructions to search atransaction history of the payor to identify a number of previoustransactions between the payor and each of the plurality of paymentrequestors, and wherein generating the listing of payment requests isfurther based on a number of previous transactions between the payor andeach of the plurality of payment requesters.
 33. The computer programproduct of claim 31, the instructions further comprising:computer-executable program instructions to receive a payment requestfrom a requester computing device; computer-executable programinstructions to associate an identifier to the request;computer-executable program instructions to search for the identifierassociated with the payment request; and computer-executable programinstructions to promote a payment request to the top of the listing ofpayment requests based on the identifier of the payment request matchingthe search criteria.
 34. The computer program product of claim 33,wherein the request identifier is randomly generated by the one or morecomputing devices.
 35. The computer program product of claim 31, theinstructions further comprising: computer-executable programinstructions to receive an input from the computing device of the payorthat the payor conducted a transaction to satisfy the payment request;and computer-executable program instructions to update the paymentrequest based on the input.
 36. The computer program product of claim31, wherein the social network information comprises a social graph ofthe payor.
 37. The computer program product of claim 31, wherein thesocial graph comprises information from at least one of a social networksite and a contacts application.
 38. A system to identify paymentrequests, the system comprising: a storage device; a network device; anda processor communicatively coupled to the storage resource and thenetwork module, wherein the processor executes application codeinstructions that are stored in the storage device and that cause thesystem to: receive a plurality of payment requests, each payment requestbeing received from a requestor computing device associated with aparticular one of the payment requesters, and each payment requestcomprising identification information of the particular one of thepayment requests, and an amount for which the particular one of thepayment requesters would like to be paid; associate a payment requestidentifier with each of the plurality payment requests; receive amessage requesting a listing of payment requests, the message beingreceived from a payor computing device associated with a payor; searchsocial network information of the payor for occurrences of the paymentrequesters to assess a strength of social network connection between thepayor and each of the plurality of payment requests; generate a listingof the payment requests based at least in part on the strength of socialnetwork connections between the payor and each of the plurality ofpayment requesters; and provide the listing of the payment requests tothe payor for display on the payor computing device.
 39. The system ofclaim 38, further comprising executable application code instructionsthat cause the system to search a transaction history of the payor toidentify a number of previous transactions between the payor and each ofthe plurality of payment requestors, and wherein generating the listingof payment requests is further based on a number of previoustransactions between the payor and each of the plurality of paymentrequestors.
 40. The system of claim 38, the instructions furthercomprising: searching for the identifier associated with the paymentrequest; and promoting a payment request to the top of the listing ofpayment requests based on the identifier of the payment request matchingthe search criteria.
 41. The system of claim 38, wherein the requestidentifier is randomly generated by the one or more computing devices.42. The system of claim 38, the instructions further comprising:receiving an input from the computing device of the payor that the payorconducted a transaction to satisfy the payment request; and updating thepayment request based on the input.